bugGNU nano - Bugs: bug #46900, justifying should be covered by...

 
 

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

bug #46900: justifying should be covered by the general undo system

Submitter:  Benno Schulenberg <bens>
Submitted:  Thu 14 Jan 2016 04:44:29 PM UTC
Votes: 3
 
Severity:  4 - Important Status:  Fixed
Assigned to:  dolorous Open/Closed:  Closed

Jump to the original submission

Mon 25 Mar 2019 01:18:13 PM UTC, comment #75: 

Released in 4.0.

Benno Schulenberg <bens>
Group administrator
Tue 20 Nov 2018 06:30:32 PM UTC, comment #74: 

Applied to master, and pushed.  The main commit is d54840c1.

Thanks very much for having worked on this issue and having fixed the one remaining undo bug.

Benno Schulenberg <bens>
Group administrator
Mon 19 Nov 2018 06:14:49 PM UTC, comment #73: 

The patch set looks good to me.  Thank you.

David Lawrence Ramsey <dolorous>
Group Member
Mon 19 Nov 2018 10:13:53 AM UTC, comment #72: 

Attached is the patch set that just makes justifications undoable and excludes the addition of justifying marked regions.  Please verify whether you can live with the commit messages.  Mostly I've just removed some repetitious sentences and rephrased things.

For the justification of marked regions I've opened a new issue: bug #55054.  See there for adjusted patches, to be applied after the current attached set.

(file #45486)

Benno Schulenberg <bens>
Group administrator
Sun 18 Nov 2018 07:51:04 PM UTC, comment #71: 

I've come as far as your patch 0011.  Patch 0012 to 0014 are not a necessary part of making justification undoable.  They add new functionality and should be a separate patch series, to be applied later.

I've merged your patch 0004 and 0005, so attached zip contains one patch less.  Only the commit messages have been condensed, and in patch 0003 two comments were condensed.  For the rest the patch series is the same as yours.

Tomorrow I will make an attempt to move the hoking-up patch to right after patch 0010, that makes do_justify() use the cutbuffer.

(file #45483)

Benno Schulenberg <bens>
Group administrator
Thu 15 Nov 2018 11:36:09 PM UTC, comment #70: 

No.  As far as I can tell, the code should be working as is.  If I've missed anything, testing by other people in ways I haven't thought of should shake out any problems.

Although the new behavior of justifying selections (as though the entire selection is a paragraph) should probably be documented somewhere.  It also means that the quoting characters of the selection are treated as part of the paragraph, which makes it more useful when there aren't any quoting characters, or just whitespace quoting characters.  (If that sounds odd, it's what current Pico does, and it's come in handy occasionally in paragraphs under those circumstances.)  Nano's equivalent is not exact, but it should be close enough, and a bit more consistent in that it won't unnecessarily add newlines after justified selections the way Pico does.

David Lawrence Ramsey <dolorous>
Group Member
Thu 15 Nov 2018 06:33:06 PM UTC, comment #69: 

Any new tweaks of your patch set?  Or can I apply the series in 3e.zip as is?

Benno Schulenberg <bens>
Group administrator
Thu 18 Oct 2018 09:46:15 PM UTC, comment #68: 

If proposed patch 0002 in bug #54861 is applied, the fill variable will be renamed to wrap_at, which will break patch 0002 of version 3e.  The attached new version of patch 0002 will apply, however; just replace the corresponding patch in version 3e with it.

(file #45241)

David Lawrence Ramsey <dolorous>
Group Member
Tue 02 Oct 2018 06:38:30 PM UTC, comment #67: 

Attached new version 3e.  Relative to 3d, it's resynced with git eb9111a, and it removes one erroneous change.

Specifically, the check for a bad quote string actually needs to be done in find_paragraph(), so that it's properly checked in both paragraph movement and justify.  Thus, patch 0004 no longer moves the check to do_justify().

(file #45125)

David Lawrence Ramsey <dolorous>
Group Member
Mon 01 Oct 2018 06:36:46 PM UTC, comment #66: 

I appreciate the help; thanks.  And I hadn't actually noticed that you could vote on bugs until now.

David Lawrence Ramsey <dolorous>
Group Member
Mon 01 Oct 2018 06:11:06 PM UTC, comment #65: 

Thanks for the update.

I've pushed a change that I made a while ago but held back so as not to disturb your work.  Attached is the updated (rebased) version of the third patch in the current set, so that the set applies cleanly to current git.

(Strangely, I now see that this bug has three votes.  Only a few bugs have had votes. For example, making indent/unindent undoable had ten votes, and the macro feature had 82 votes.)

(file #45123)

Benno Schulenberg <bens>
Group administrator
Sun 30 Sep 2018 07:09:15 PM UTC, comment #64: 

Thank you.

To make things a bit easier, I'm attaching version 3d, resynced against 13a4f31 and thus four patches smaller :)  It's been working in my testing so far, but more testing certainly won't hurt.

(file #45121)

David Lawrence Ramsey <dolorous>
Group Member
Sun 30 Sep 2018 06:52:26 PM UTC, comment #63: 

Okay, I've applied the first four patches -- the ones that don't change or break any behavior.  Now comes the harder work of looking into the behavior changes.

Benno Schulenberg <bens>
Group administrator
Sat 29 Sep 2018 04:02:49 AM UTC, comment #62: 

Attached new version 3c.  Relative to version 3b, it resyncs against git 0b63de3.

(file #45116)

David Lawrence Ramsey <dolorous>
Group Member
Fri 28 Sep 2018 02:55:41 PM UTC, comment #61: 

Attached new version 3b. Relative to version 3a, it resyncs against git bed9971, and adds a new patch 0020 (which removes references to the inability to undo justifications in the manual and info pages).

(file #45113)

David Lawrence Ramsey <dolorous>
Group Member
Tue 25 Sep 2018 08:52:53 PM UTC, comment #60: 

Attached new version 3a.  Relative to version 3, it resyncs against git efa323e (so it works with your fix for bug #54728), and removes some unneeded variable usage in patch 0019 (using the buffer operations directly instead of the cutting code means that the mark isn't unset, so it doesn't need to be saved).

(file #45099)

David Lawrence Ramsey <dolorous>
Group Member
Tue 25 Sep 2018 04:18:46 PM UTC, comment #59: 

For the "fumbling code" I have created a new "bug" report: bug #54728.  Please verify whether you agree with my reasoning there.

Benno Schulenberg <bens>
Group administrator
Tue 25 Sep 2018 02:51:21 PM UTC, comment #58: 

Attached new version 3 (since there are no more letters after 2z).   It's still against git c545438.  Relative to 2z, it updates patch 0019: your second patch to allow undo_update(PASTE) is melded for testing purposes, and the cursor positions before and after the user presses ^J are now properly restored on unjustify.

(Saving the cursor position before justify would normally require making update_undo() work on COUPLE_BEGIN, but that would require changing the current cursor position twice: once from the beginning of the paragraph to where it actually started, and again afterwards to put it back at the beginning of the paragraph.  And considering that it has to save the line number rather than the line pointer, calling fsfromline() to turn one into the other would make things even slower than they already are.  With the way the generic undo system is currently designed, it's much easier to just manually update the cursor position stored in COUPLE_BEGIN, since we already manually update the undo description to "justify" there.)

Barring any major bugs with actual justify/unjustify, the documentation still needs to be updated to e.g. remove any references to nano's being unable to undo justify.

(file #45093)

David Lawrence Ramsey <dolorous>
Group Member
Mon 24 Sep 2018 07:16:50 PM UTC, comment #57: 

Your second patch, added on top of mine, does seem to fix things, after some quick testing on my part.  Thank you.  And my typing isn't that good when I'm tired, either :)

As for why the code adds undo items, look at text.c just before the undo_cut() and redo_cut() functions:

#define redo_paste undo_cut
#define undo_paste redo_cut

This reuse of code may save space, but it also makes things more confusing.  As for why PASTE undo items weren't updated before, it may have been an oversight: there is code in update_undo() to handle PASTE, even if the update wasn't actually done.

I suppose some testing of the calls of update_undo(PASTE) is in order, to make sure that things aren't broken.  Aside from the new usage in the justify code, it seems to only be done in do_uncut_text().

David Lawrence Ramsey <dolorous>
Group Member
Mon 24 Sep 2018 06:14:08 PM UTC, comment #56: 

I meant: it does two undo adds.  And: that it should not update an undo item.  (Typing becomes poor when I'm tired.)

Benno Schulenberg <bens>
Group administrator
Mon 24 Sep 2018 06:10:37 PM UTC, comment #55: 

Hi David,

It seems the mistake was a simple oversight.

I added two print statements to the code (see attached first patch), and then pressed ^J on the first paragraph of the NEWS file, and then exited without saving.  This is what it printed:

Adding undo type 0x11
Adding undo type 0xd
Updating undo type 0xd
Adding undo type 0xf
Adding undo type 0xf
Adding undo type 0x12

Apparently 0x11 is COUPLE_BEGIN, 0x12 is COUPLE_END, and 0xd is CUT.  But... it does undo adds for PASTE.  Aaah!  Somehow the special fumbling code at the start of update_undo() thinks that it should update an undo item but create a new one.

With the second patch applied, things seem to work fine.  I'm not sure this is the proper fix -- because why was PASTE not among those conditions before?

(file #45087, file #45088)

Benno Schulenberg <bens>
Group administrator
Mon 24 Sep 2018 05:07:35 PM UTC, comment #54: 

Argh.  Attached updated version 2z.  It's still against git c545438.  Relative to 2y, the hookup to the undo system in patch 0019 is simpler, and it also builds in tiny mode with --enable-justify again.

I've noted that if you justify in the middle of a paragraph and undo, when the undo works properly, the cursor is put back at the beginning of the paragraph instead of where it was when you pressed ^J.  This needs to be fixed as well, but the instances where unjustify malfunctions are obviously higher priority right now.

(file #45085)

David Lawrence Ramsey <dolorous>
Group Member
Mon 24 Sep 2018 04:46:11 PM UTC, comment #53: 

Okay.  Thanks again for the info.

I've at least figured out part of the problem: using do_uncut_text() runs add_undo(PASTE) and update_undo(PASTE).  Since the last version of the patchset does those before and after do_uncut_text(), it ends up adding far too many paste undo items.

The new attached version, 2y, is resynced against git c545438.  It fixes the problem with extra paste undo items by manually pasting the text, as well as making justification of selected text work again (hooking it up to generic undo broke it in the last version).  It also removes a spurious else in patch 0016 (which first added justification of selected text).

In this patchset, undo is less broken; it works properly in some circumstances, but not in other circumstances I haven't figured out yet.  Since the undo code has to save line numbers for both the current line and the mark in order to undo a marked cut, and justifying is the one case where cut text is followed by a paste of different text, I think the line numbers are getting thrown off somewhere, so the cutting/pasting gets done on the wrong lines.

(file #45084)

David Lawrence Ramsey <dolorous>
Group Member
Sun 23 Sep 2018 06:07:31 AM UTC, comment #52: 

(The HARDMARK/SOFTMARK setting is only relevant when deciding whether a cursor movement (without Shift) should cancel the mark.  It has no importance anywhere else.)

Another exaxmple: src/nano --ignore --line --fill=66 README, and then type: ^J  M-U (Undid cut)  M-U (Undid justify)  M-U (Nothing to do),  M-E (Redid paste)  M-E (Redid justify)  M-E (Nothing to do).

The first M-U cuts the third line (which is blank) instead of the second line.  The first M-E pastes the actual line that was cut (the second, the title) into the third line, so that now the title is duplicated.  Somehow the stored line number is off by one when a ^J does not start on a paragraph?

When doing just one M-U after the ^J, then the first M-E redoes a cut.  And it takes three further M-Es before the top of the stack is reached.  This is weird!  One undo requires four redos?  Somehow the stack items seem to get spaghettied.  Because, when doing M-U M-U M-E M-E, also the order of undos and redos is not the inverse.

Benno Schulenberg <bens>
Group administrator
Sun 23 Sep 2018 01:02:37 AM UTC, comment #51: 

Thanks for the info.  That at least narrows it down.  I'm not in front of my development machine right now, so I can't look at the code as a whole right now, but I think part of the problem is that the faked marked cut of the unjustified text doesn't set openfile->kind_of_mark to anything, so it's left as SOFTMARK by default (instead of HARDMARK), which may affect things.  I'll look into it as soon as I can.

David Lawrence Ramsey <dolorous>
Group Member
Sat 22 Sep 2018 09:18:08 AM UTC, comment #50: 

I looked at the behavior of your patch set two weeks ago, but couldn't "make chocolate from it" -- meaning I didn't understand what was happening when I pressed Undo.

For example: src/nano --ignore --line --fill=66 NEWS, then press ^J and M-U.  See that it has not only removed the first five lines of the justified paragraph, but also the first nine lines of the subsequent paragraph.  Another M-U "eats" another four lines of that paragraph.  It seems that the end point of what to cut is not set or stored correctly.

Benno Schulenberg <bens>
Group administrator
Thu 20 Sep 2018 08:36:49 PM UTC, comment #49: 

Attached new version.  No changes from before except for a resync against git 790f985.

Barring any other significant bugs I find in the refactor, I can't do much else with this other than resyncs.  At least not without some feedback, or some help fixing the actual undo support in the last patch in the set.

(file #45067)

David Lawrence Ramsey <dolorous>
Group Member
Thu 13 Sep 2018 05:54:10 PM UTC, comment #48: 

Forget the part in comment #47 how the cursor isn't put back where it was before justifying.  That's handled properly by the COUPLE_BEGIN/COUPLE_END parts, which were commented out; sorry for the confusion.

nano's generating 5 undo events for a cut+paste when it should only generate 2 is the only real problem.

David Lawrence Ramsey <dolorous>
Group Member
Thu 13 Sep 2018 04:35:35 PM UTC, comment #47: 

I'm still looking into the last patch of the set, to try and fix the actual hookup to the undo system.  I've locally commented out the bits of nano that add COUPLE_BEGIN and COUPLE_END, so the justify/unjustify should be two undo items: a cut followed by a paste.  However, it actually ends up being 5(!) items.  With the attached file (I would use a file included with nano, but I need something simple), try the following:

1. Apply the patch set to current git (fe3a72c), and then comment out text.c's lines 2336, 2337, 2379, and 2380 (the COUPLE_BEGIN and COUPLE_END lines).

2. Run:

./nano +1,1 justify-small-test.txt

The file now consists of:


this is
a test


3. Press ^J to justify the paragraph.  The status bar will display "Justified paragraph".

The file now consists of:

this is a test


and the cursor is on the magicline, on line 2.

4. Press M-U until the paragraph is unjustified.

Try 1: The status displays "Undid action (text uncut)".  The file and cursor position do not change.

Try 2: The status bar displays "Undid action (text uncut)".  The file and cursor position do not change.

Try 3: The status bar will display "Undid action (text uncut)".  The file and cursor position change: the file is now empty, and the cursor is at the beginning of the file.

Try 4: The status bar will display "Undid action (text uncut)".  The file and cursor position do not change from try 3.

Try 5: The status bar will display "Undid action (text cut)".  The file and cursor position change:

The file now consists of:

this is
a test


and the cursor is on the magicline, on line 3.  Only on this step is the unjustified text put back.

Obviously, this is incorrect behavior.  (Also, the cursor isn't put back where it was before justifying, and it should, but that's a much smaller problem compared to this.)

(file #45000)

David Lawrence Ramsey <dolorous>
Group Member
Tue 11 Sep 2018 04:10:25 PM UTC, comment #46: 

Attached another version: 2x. It's still against git 5b12295.

Relative to 2w, it fixes a few more inaccurate comments in patch 0011.  bot_inpar is supposed to only be set when the last line of the file is part of the paragraph, but it can also be set if nano's search for a paragraph can't go any farther because there aren't any more paragraphs.  The code dealing with bot_inpar is complex enough, so the comments only mentioning the first possibility need to be changed.

(file #44981)

David Lawrence Ramsey <dolorous>
Group Member
Tue 11 Sep 2018 08:06:44 AM UTC, comment #45: 

Attached one more version: 2w. It's still against git 5b12295.

Relative to 2v, it fixes a few cases of cursor misplacement when the paragraph search puts the cursor at the end of the file; it should always go to the end instead of sometimes to the beginning when the last line isn't in a paragraph, since the last line may not be blank even if it isn't in a paragraph.  It also fixes a few cases of indentation with spaces instead of tabs.

(file #44979)

David Lawrence Ramsey <dolorous>
Group Member
Tue 11 Sep 2018 07:16:48 AM UTC, comment #44: 

Attached one last version: 2v. It's still against git 5b12295.

Relative to 2u, it fixes a case in find_paragraph() where there are no paragraphs after the current line more cleanly.  Patch 0010 makes the function work on its own buffer, but the removal of x-coordinate handling makes it more difficult to check for that case.  This version adds a new patch 0011 that checks for it without having to set quote_len and par_len unnecessarily, and using almost the same check that's also done at the start of the function.  (We have to check twice: once before we move in our search for a paragraph, in case there isn't one; and again after we move, in case we didn't find one.  The second check only applies if the last line of the file is supposed to be in a paragraph but isn't, which we can only determine after we've moved.)

As for why it's in a separate patch, patch 0010 is a straight port of the logic that's already there from the main buffer to its own buffer, and new patch 0011 switches some of that logic around to accomplish what it needs to; it's less confusing that way.

(file #44978)

David Lawrence Ramsey <dolorous>
Group Member
Tue 11 Sep 2018 06:20:22 AM UTC, comment #43: 

Argh.  Attached version 2u. It's still against git 5b12295.

Relative to 2t, it fixes one oversight, adding a new patch 0005.  justify_format() already worked on its own buffer, but it assumed it was working on the current buffer and still did its own totsize and mark handling.  The totsize handling meant that it would throw the value of totsize out of whack, since extract_buffer() and ingraft_buffer(), and the cutting functions that use them, already do totsize handling.  This is now fixed; justify_format() loses these bits just before the patch converting justify_paragraph() to work on its own buffer.

Barring any further bugs I find, this version seems stable enough, aside from the last patch brokenly hooking it up to undo.

(file #44977)

David Lawrence Ramsey <dolorous>
Group Member
Tue 11 Sep 2018 04:51:46 AM UTC, comment #42: 

And finally, attached version 2t. It's still against git 5b12295.

Relative to 2s, it fixes a few uninitialized variable warnings in the code to restore the mark after justifying marked text.

(file #44976)

David Lawrence Ramsey <dolorous>
Group Member
Tue 11 Sep 2018 03:10:38 AM UTC, comment #41: 

Argh.  Attached version 2s. It's still against git 5b12295.

Relative to 2r, it removes a bit of code in the last patch that's redundant after converting do_justify() to use the cutting functions, and updates the commit message to mention this.

(file #44975)

David Lawrence Ramsey <dolorous>
Group Member
Tue 11 Sep 2018 02:56:35 AM UTC, comment #40: 

Attached version 2r.   It's still against git 5b12295.

Relative to 2q, it makes the mark cover newly justified marked text.

Effectively, everything seems to work now after some quick testing, except for actually hooking it up to undo in the last patch of the set.  As in, if you want to help test refactored justify so I can be sure I got it right, apply all patches but the last one for testing.

(file #44974)

David Lawrence Ramsey <dolorous>
Group Member
Tue 11 Sep 2018 12:12:15 AM UTC, comment #39: 

Attached version 2q.  It's still against git 5b12295.

Relative to 2p, it fixes more references to unjustify in patch 0010, there are new patches to remove unnecessary variable initializations, implement justifying marked text (it doesn't make the mark cover the newly justified text afterward yet, although it should), and clean up things after the addition of justifying marked text.  The final patch is still the (broken) attempt at hooking it up to the undo system.

(file #44973)

David Lawrence Ramsey <dolorous>
Group Member
Mon 10 Sep 2018 09:58:11 PM UTC, comment #38: 

Attached version 2p.  It's been resynced against git 5b12295.

Relative to 2o, it adjusts patch 0009 so that find_paragraph() properly catches the case of no paragraphs after the current line (without using bot_inpar, which was hackish anyway), adds patches 0010 and 0011 to remove the old unjustify routine, and adjusts patch 0012 (formerly 0010) to display proper statusbar messages for justifying a paragraph or a file.

Note that marked justify is still undone, and the last patch to hook justify up to the undo system is still broken (maybe undo_paste()'s and redo_paste()'s being macros for redo_cut() and undo_cut() are part of the problem?).

(file #44971)

David Lawrence Ramsey <dolorous>
Group Member
Sun 09 Sep 2018 03:25:20 PM UTC, comment #37: 

After some more thought, hypothetical justify-marked-text-like-newer-Pico should work like Pico's and justify the entire selection as though it's one paragraph.  It could be useful in cases of odd formatting that keep ordinary justify from working, and it's the only way to justify everything in that fashion.  As for what nano should do for a full-justify when the mark is on... I figure it should do the same, since, as I've said before, Pico's behavior of doing nothing is worse than redundancy with ordinary justify.  (Also, my earlier proposal for it would involve justifying only part of a selection if the selection didn't start with a paragraph, in order to match all the other forms of justify.  Checking for that case just to avoid marking the file as modified, as all the other forms do, would lead to a lot more code complexity.)

More importantly, I figure I'll go ahead with the proposed unjustify changes in comment #36.  They're minor enough that they're easy to change, and, if they're done first, the only problem left is that of the COUPLE_BEGIN/COUPLE_END issues (and after those are solved, this bug can finally be closed).  I'll get to this when I next have enough time to code.

David Lawrence Ramsey <dolorous>
Group Member
Sat 08 Sep 2018 04:06:42 PM UTC, comment #36: 

For the record, if you're wondering why the last patch set still has the old unjustify code in it, it's because I'm not sure what to do with it.  Otherwise, I would have removed it before trying to add the new unjustify code.  Specifically, I'm concerned about how much of the old behavior we should keep.

1. If justify is hooked up to the generic undo code, do we really need to temporarily make Ctrl-U act as UnJustify instead of UnCut anymore?  On the other hand, removing that behavior might lead to confusion if nano still produces the "Can now UnJustify!" message after justifying.

2. Given the issue with the unjustify message in (1), should it change as well?  First, if nano-tiny built with justify will no longer be able to unjustify, it's inaccurate.  Second, removing it entirely might lead to confusion as well, since the only indication that nano justified anything will be whether the file is marked as modified (and if it was marked as such before justifying, that's not enough).

I'd personally lean toward solving (1) by removing the Ctrl-U-as-unjustify behavior, and solving (2) by at least changing the message to "Justified" (ideally, I'd make it convey more information than that, and display "Justified paragraph", "Justified file", and "Justified selection" for justify, full-justify, and hypothetical justify-marked-text-like-newer-Pico, respectively).

David Lawrence Ramsey <dolorous>
Group Member
Fri 07 Sep 2018 05:17:23 PM UTC, comment #35: 

Attached version 2o, also against git 3270aac.

Relative to 2n, it adds patch 0011, which starts hooking justify up to the undo system.  There are a few things still left undone: the mark isn't handled yet, and the old unjustify routine is a large chunk to remove, so it's still in place.  This means that, to test it, you'll have to justify a paragraph, press some key other than ^U or M-U (such as an arrow key) to avoid the old unjustify code, and then try to unjustify.

However, making it use COUPLE_BEGIN and COUPLE_END is causing some problems.  When I try to undo a justify, nano thinks I'm trying to undo the uncut, and when I modify update_undo() to not try to cleverly add a new entry for the paste instead of updating it (really, shouldn't the function take some kind of flag to indicate "don't do this", instead of having hardcoded exceptions?), nano thinks I'm trying to undo the cut.  So, I'm stumped for now, unless you can help me figure out what's going on.

(file #44954)

David Lawrence Ramsey <dolorous>
Group Member
Fri 07 Sep 2018 12:52:01 AM UTC, comment #34: 

Attached version 2n, resynced against git 3270aac.

Relative to 2m, the only changes are the removal of the last mark-related code in do_justify() in patch 0005; the restoration of a check for justifying at the end of the file in patch 0009 (done using bot_inpar, since current_x is not available outside the main buffer; this is necessary to make sure find_paragraph() returns FALSE properly under such circumstances); and a much improved and cleaned-up version of patch 0010 (it's no longer considered temporary, and full-justify now works with it, although unjustify is still broken; unjustify should be fixed in a later patch, since fixing justify and full-justify in one patch is complex enough).

(file #44948)

David Lawrence Ramsey <dolorous>
Group Member
Sat 01 Sep 2018 12:56:43 AM UTC, comment #33: 

Attached version 2m, also against git 13615d0.

The only changes relative to 2l are a fix in patch 0009 for a badly wrapped comment, plus an attempt in new patch 0010 to make do_justify() justify text using the cutbuffer.

Note: patch 0010 is experimental, messy, and not meant to go in as-is; it's merely a demonstration of how to make do_justify() work the new way.

Patch 0010 doesn't handle full-justify properly: full-justify should put the current paragraph plus the rest of the file in the cutbuffer, and then justify and scan through the cutbuffer until all paragraphs are done.

Patch 0010 also completely breaks unjustify: unjustify is unchanged from the old code, and so still expects the old justify mechanism, which is no longer there.

And, obviously, the mark is not handled under the new code in patch 0010 at all; that can wait until all of justify properly works the new way.

(file #44918)

David Lawrence Ramsey <dolorous>
Group Member
Fri 31 Aug 2018 09:45:23 PM UTC, comment #32: 

Attached version 2l, also against git 13615d0.

Relative to 2k, in patch 0009, it actually moves checks for whether the last line of the file is part of the current paragraph from justify_paragraph() to find_paragraph().  Accordingly, it also moves all x-coordinate handling to do_justify(), since only that function should work on the current buffer; the other functions now work on their own buffers.

(file #44917)

David Lawrence Ramsey <dolorous>
Group Member
Fri 31 Aug 2018 09:07:52 PM UTC, comment #31: 

...and forgot to mention one last change in 2k: when full-justifying, current_x is properly set to the end of the last line of the file, as is already done for justify.

David Lawrence Ramsey <dolorous>
Group Member
Fri 31 Aug 2018 09:05:11 PM UTC, comment #30: 

Attached version 2k, which is resynced against 13615d0, and cleans up a few bits from previous versions.

Specifically, patch 0005 really removes all the mark handling (older versions left one bit of softmark handling in), and patch 0007 moves the quoterc message after all the variable declarations, in case some of them are needed after the overhaul is complete.

Checking whether the last line of the file is part of the current paragraph should ideally be moved from justify_paragraph() to find_paragraph(); if it's true in the latter, it should be true in the former as well.  That change should be the next step, before starting to port everything to use the cutbuffer.

(file #44916)

David Lawrence Ramsey <dolorous>
Group Member
Fri 31 Aug 2018 05:49:45 PM UTC, comment #29: 

And, finally, attached version 2j, which is also against git 921f8ae.  Relative to 2i, it makes find_paragraph() work on its own buffer.

(file #44914)

David Lawrence Ramsey <dolorous>
Group Member
Fri 31 Aug 2018 04:59:57 PM UTC, comment #28: 

And now attached version 2i, which is also against git git 921f8ae.  Relative to 2h, it makes justify_paragraph() a bit simpler; the fix in 2h shouldn't use two pointers when one will do just as easily.

(file #44913)

David Lawrence Ramsey <dolorous>
Group Member
Fri 31 Aug 2018 04:15:18 PM UTC, comment #27: 

Looked at it in detail (and sorry I missed a few details of your bug report before).  The problem was that par_len was the wrong variable to use to indicate the paragraph length, since it continually shifted.  Good catch.

Attached version 2h, which is resynced against git 921f8ae and should fix this problem.  Patch 0005 in the set now makes things a bit more like the original code: it now returns a pointer to the line following the paragraph instead (which it will need once it's put in the cutbuffer via extract_buffer(), and put back justified via ingraft_buffer()).  justify_paragraph() doesn't change current directly anymore, as renumbering it can be done outside it in do_justify(), and will need to be done there once justifying is done in the cutbuffer.

(file #44912)

David Lawrence Ramsey <dolorous>
Group Member
Wed 29 Aug 2018 09:00:56 PM UTC, comment #26: 

Without looking at it in detail, I think it's probably some other effect of the temporarily removed bits of justify.  The routine to move current to the end of the paragraph that the patch adds is really a temporary hack to make things not completely broken (and, as you can see, it's not perfect).

Besides, the patch does warn that it breaks justify in the commit message.  Moving everything to the cutbuffer in one step would be too complex to do in only one patch; some things won't work quite right until it's done, because it's a work-in-progress right now.

As I said, I won't have time to look at it for at least a few days.  When I get back to it, I'll first hook it up to the cutbuffer via extract_buffer(); that function should put current, edittop, and whatever else back in place properly.

David Lawrence Ramsey <dolorous>
Group Member
Wed 29 Aug 2018 07:19:04 PM UTC, comment #25: 

Yes, the first paragraph is still properly justified (that's why I used --fill=90, to be able to see the change), but because the cursor goes to line 3, a second ^J just justifies the first paragraph again, and thus after the first ^J any further consecutive ^J has zero effect.  The cursor stays "stuck" on the third line.

Benno Schulenberg <bens>
Group administrator
Wed 29 Aug 2018 05:29:48 PM UTC, comment #24: 

If you're using an 80x24 screen when you do that, the third paragraph of NEWS ends after the bottom of the screen.  Since patch 0005 temporarily removes handling of edittop, this could be just a display glitch, caused by edittop's being in the wrong place after justifying.  I've seen it sometimes while testing; going through the code with gdb shows that the text is properly justified.

It should be fixed once I finish porting find_paragraph() to work on its own buffer.  After that, it should be simple to (a) move the text to be justified into the cutbuffer (since marked cut isn't in tiny mode, extract_buffer() will work, since cut_marked() is really just a wrapper for extract_buffer()), (b) justify the text of the cutbuffer, (c) in the case of full-justify, search for the next paragraph and justify that until all paragraphs in the cutbuffer are justified, and (d) paste the justified text back.  The new code should be similar to the old in that justify will put one paragraph into the cutbuffer, and full-justify will put the paragraph and all text after it into the cutbuffer (since we don't know how many there are in advance).

As for what to do about the mark, Pico behaves as follows when the mark is on: justify treats every line of the marked text as part of the same paragraph, regardless of quoting; and full-justify does nothing.  I consider the former a bug due to its ignoring quoting, and the latter a bug because the key should either do something or give feedback as to why it did nothing.  I figure that, when the mark is on, nano should justify each paragraph of the marked text separately (so, effectively, it would be a full-justify of just the marked text).  As for full-justify, I'd make it do the same; yes, it's redundant, but I think doing nothing is worse, and it's still full-justify in a sense, regardless.

Thanks for the feedback, in any case.  I won't have time to work on this for at least the next few days, but soon.

David Lawrence Ramsey <dolorous>
Group Member
Wed 29 Aug 2018 04:32:52 PM UTC, comment #23: 

Patch 0005 says that current is still moved to the end of the paragraph, but... this appears not to be the case when I try to justify the NEWS file: src/nano --ignore --fill=92 +1 NEWS, and then type: ^J ^J ^J...  The cursor stays stuck on the third line of the paragraph.

Benno Schulenberg <bens>
Group administrator
Tue 28 Aug 2018 04:14:48 PM UTC, comment #22: 

Version 2g is attached; it's against the same git version as 2f, 93c8e31.

Relative to 2f, it removes some unnecessary setting of current_x in find_paragraph() (current_x will only be set to a nonzero value if the last line of the file is in the paragraph), and prepares to make find_paragraph() work on its own buffer by moving some main buffer-related bits of it to do_justify() (the check for a bad quoterc; and the check for being at the end of the file, but only after having found at least one paragraph, so that existing behavior is preserved).

(file #44887)

David Lawrence Ramsey <dolorous>
Group Member
Tue 28 Aug 2018 01:13:31 AM UTC, comment #21: 

And, finally, version 2f; attached.

It's against the same git version as 2e.  Relative to 2e, lastline_inpar is no longer passed as a reference in the functions that use it; instead, those functions return a bool indicating what lastline_inpar would be, which makes things much simpler.  Also, do_para_begin() and _end() now operate on their own buffers; do_para_begin_void() and _end_void() handle all screen updates, since they're tied to the main buffer.

This last change requires some extra setting of current_x in do_justify() for now, but that should only be the case until I port it to work on the cutbuffer instead of the main buffer.  It's needed to eventually make full-justify undoable; ordinary justify works on one paragraph and stops, but full-justify works on a paragraph and searches for the next one until there aren't any more, so there has to be a way to search for paragraphs outside the main buffer.

(file #44883)

David Lawrence Ramsey <dolorous>
Group Member
Mon 27 Aug 2018 09:23:13 PM UTC, comment #20: 

And now version 2e; attached.

The only changes relative to 2d are that it's been resynced against git 93c8e31; and that the last patch to make justify_paragraph() work on its own buffer (a) removes a bit of unnecessary code (jusline doesn't need to be moved down one line after the paragraph is justified, only checked to see if there's a line after it in order to set lastline_inpar), (b) clarifies comment descriptions of what lastline_inpar actually means, and (c) updates the commit message to mention that it temporarily breaks handling of edittop as well as totsize and the mark.

(file #44879)

David Lawrence Ramsey <dolorous>
Group Member
Mon 27 Aug 2018 06:26:59 PM UTC, comment #19: 

Argh; make that version 2d.  In this (attached) version, handling the case where the last line of the paragraph is the last line of the buffer now no longer duplicates code unnecessarily; the variable for that case is now named lastline_inpar, since filebot_inpar no longer makes sense now that it's using its own buffer; and unnecessary tweaks have been removed.

(file #44878)

David Lawrence Ramsey <dolorous>
Group Member
Mon 27 Aug 2018 05:50:26 PM UTC, comment #18: 

And now, I've updated to version 2c.  Relative to 2b, it fixes a minor indentation error, and, more importantly, makes justify_paragraph() work on its own buffer while properly moving current to the end of the paragraph afterwards (although totsize handling and mark handling are still gone).  Attached.

(file #44877)

David Lawrence Ramsey <dolorous>
Group Member
Mon 27 Aug 2018 03:49:25 AM UTC, comment #17: 

Added one more update: I'm calling it version 2b.  It's against the same version of git as 2a, 80bea3e (although with the fix to bug #54573 applied first, to keep things sane).

I've thought about it some more, and justify_paragraph() should work on its own buffer as part of making justify undoable.  Version 2b takes steps toward this: the function now properly justifies a paragraph in the passed-in buffer.  However, to do this, I've had to temporarily remove the bits of it tied to the current file buffer: totsize handling, mark handling, and moving current to the end of the paragraph are gone for now.

This means that, with 2b applied, justifying an individual paragraph works, but nano's handling of it afterwards is completely broken, to say nothing of full-justifying.  This should be fixed eventually, once I add the code to get unjustified text into the cutbuffer and unjustified text out: as I've said before, probably by a marked cut of the former (which will avoid the hackish filebot_inpar stuff), followed by a paste of the latter.

(file #44873)

David Lawrence Ramsey <dolorous>
Group Member
Sun 26 Aug 2018 11:42:37 PM UTC, comment #16: 

Argh.  The added patch in the last update was supposed to adjust only one comment, but added an unnecessary code change.  Not to mention, there was a typo in the comment.

Attached refactor version 2a, which is what the last one should have been.  The comment adjustment is moved to the first patch with the other ones, so the patchset is back to 4 patches total, with cosmetic adjustments only in the last patch.  With the fix to bug #54573 applied, everything still seems to work so far.

(file #44872)

David Lawrence Ramsey <dolorous>
Group Member
Sun 26 Aug 2018 03:55:56 PM UTC, comment #15: 

Made one last update to the refactor; attached.  It's against git 80bea3e, and adds one last adjustment.  Specifically, one comment is unclear about what last_par_line is set to when full-justifying if we run out of paragraphs (i.e. the last line of the file is not part of a paragraph); it's cleared up with the added patch.

Although in the process of testing that condition, I found a bug that doesn't seem to be my work; I'll be reporting that separately.

(file #44865)

David Lawrence Ramsey <dolorous>
Group Member
Sat 25 Aug 2018 11:14:34 PM UTC, comment #14: 

The refactor was getting unnecessarily complicated, plus it duplicated and/or reshuffled a few things unnecessarily or in ways that caused breakage.

Attached justify refactor version 2, against git b5ede4f.  It accomplishes the same as the last one, but in a hopefully better way so far.

As for how to accomplish generic undo (discounting the hypothetical marked justify for now), I'm thinking:

1. Drop unjustify from tiny mode.

2. Do a marked cut of the original paragraph(s) for the first half of COUPLE_* undo (which disallows tiny mode anyway; this is needed because the last line of the file may or may not be part of the paragraph, so the simple cut-to-eof that the alt spell checker's undo uses may not be accurate here).

3. Justify the text in the cutbuffer.  Since rewriting all the paragraph- and justify-related code to work on generic buffers would be a massive amount of work, the easier approach would probably be to temporarily make nano treat the cutbuffer as the file when justifying.

4. Uncut (paste) the justified text from the cutbuffer back into the file for the second half of COUPLE_* undo.

(file #44864)

David Lawrence Ramsey <dolorous>
Group Member
Thu 23 Aug 2018 07:17:26 PM UTC, comment #13: 

Worked on the justify refactor some more.

The attached patch set is against git 8d6b205.  It builds on the last one.  Importantly, it finally implements your suggestion of moving the routine to justify a paragraph into its own function.

It contains several commits adjusting comments and indentation, like the last one, and they could probably be consolidated eventually, but right now I'm focusing on keeping things working and making the comments clearer and/or more accurate when I can.

Note that justify and full-justify are still not hooked up to the undo system by this patch set.  That being said, the refactoring in this patch set should make it much easier to eventually hook them up.

(file #44839)

David Lawrence Ramsey <dolorous>
Group Member
Wed 22 Aug 2018 06:43:52 PM UTC, comment #12: 

I've started over on refactoring justify, in order to take a cleaner approach than last time.  The justify code as it is now is similar to the line-indent code before it was hooked up to undo: two functions that should be separate (justify and full-justify) are coupled together in a way that saves lines of code, but also makes things much harder to work with.  So I've started with that, which means that there is currently some duplication of code, but that should be fixed eventually in the process of making things undoable.

(There is one issue with making things undoable that needs to be resolved, though.  When justify and full-justify are finally hooked up to the undo system, that means that they won't be undoable by that means in tiny mode, since tiny mode leaves out the undo system.  The existing undo mechanism for justify does match what Pico does, and does work in tiny mode if you build with --enable-tiny --enable-justify, but preserving both it and the generic undo system will be overly complicated.  I'd be in favor of removing the existing undo mechanism in that case, since unjustifying in tiny mode doesn't seem to be widely used, and it would be a lot less work.  Would you be in favor of that as well?)

The attached patch set is against git 03f9761, and does the following so far: it copies do_justify() into do_justify_void() and do_full_justify(); it renames do_justify_void() to do_justify() and removes the original do_justify(); and it starts disentangling justify and full-justify in terms of code.  The last of these steps does include removing redundant checks for having justified something, as in the last patch set.

(file #44825)

David Lawrence Ramsey <dolorous>
Group Member
Thu 09 Aug 2018 01:20:58 AM UTC, comment #11: 

I'll get back to this as soon as I can.  (Hooking up the alternate spell checker to undo/redo involves some of the same issues that hooking up justify to undo/redo will have to deal with, but the former is simpler than the former because it already works on its own buffer instead of within the file, which is why I went with it first.  Also, some of the ways COUPLE_BEGIN/COUPLE_END have been extended for alternate spell-check will be used by justify as well, so some of the work is already done.)

After some thought, the proposed approach of having a function that's called once by ^J and multiple times by M-J may not be as feasible as it sounds, given their different requirements of how much of the file to back up.  Justifying multiple non-contiguous paragraphs while preserving the text between them is the main problem that this approach doesn't handle well.  So, instead...

What about a function that takes a buffer, and then scans through and justifies all paragraphs in that buffer, leaving non-paragraph parts of that buffer untouched?  The main differences between justify modes would then be as follows:

^J: Scan for next paragraph in the file.  Put that paragraph in the buffer.  The function scans for and justifies all paragraphs in the buffer: only that one paragraph is found and justified, as expected.

M-J: Put the entire file in the buffer.  The function scans for and justifies all paragraphs in the buffer: all paragraphs in the file are found and justified, as expected.

Hypothetical ^J with mark on: Scan for next paragraph within the marked text.  Put that paragraph in the buffer.  The function scans for and justifies all paragraphs in the buffer: only that one paragraph within the marked text is found and justified, as expected.

Hypothetical M-J with mark on: Put all the marked text in the buffer.  The function scans for and justifies all paragraphs in the buffer: all paragraphs within the marked text are found and justified, as expected.

David Lawrence Ramsey <dolorous>
Group Member
Sat 28 Jul 2018 09:42:42 PM UTC, comment #10: 

I wonder whether the justify code as it is needs to be restructured first in order to make this easier.  As things are, the first patch in the zip file (the one to remove redundant checks for having justified something) could probably go into the current code after sufficient testing.

David Lawrence Ramsey <dolorous>
Group Member
Sat 28 Jul 2018 09:20:45 PM UTC, comment #9: 

Started trying to make justify work in its own buffer.  It's still unfortunately broken in some ways, which are documented in the commit messages.

It's against the same git version, and is now a sequence of 4 patches in the attached zip file.

(file #44648)

David Lawrence Ramsey <dolorous>
Group Member
Fri 27 Jul 2018 05:24:05 AM UTC, comment #8: 

Attached an improved rough attempt, still against the same git version.  It now tweaks comments only when necessary, and it's been split into two patches.

The first patch removes the redundant checks for having justified something (the simpler task), and the second patch splits out the justification function for justify/full-justify (the more complex task).  The problems it causes are unchanged so far, unfortunately.

(file #44633, file #44634)

David Lawrence Ramsey <dolorous>
Group Member
Thu 26 Jul 2018 04:56:19 AM UTC, comment #7: 

Attached first, very rough attempt at splitting out the justification function for justify/full-justify: against git f82eefa.

It tweaks a few comments, but doesn't adjust indentation yet.  I have no idea how useful you might find it, but I figure it's a start.

The major problem with it is in the backup_lines() call: doing a full-justify seems broken, but if you comment out the backup_lines() call, you can see that the attempt to save the original lines for unjustifying is the real source of the problem.  It's documented more in the commit message for now.

(file #44623)

David Lawrence Ramsey <dolorous>
Group Member
Tue 24 Jul 2018 11:43:15 PM UTC, comment #6: 

Not yet.  I've been busy the past few days, and when I'm not, I'm still studying the justify code to get back up to speed on it.  It's been ages since I looked at it in much detail.  [Not to mention, I've occasionally gotten distracted by other, much easier to squish bugs :).]  Also, the COUPLE_BEGIN and COUPLE_END undo routines aren't that well documented; I know it's several undos/redos at one time, but a few more comments would be helpful to indicate what's being undone/redone, without having to keep digging into the git history.

Although if you're looking at it too, that should be a big help.  Pulling ^J and M-J out of each other is a good first step (since revamping them to work on a passed-in buffer rather than the current file buffer is needed, but much more difficult, so we really should take the easier steps first), and  putting it in a branch is definitely the right approach.  I don't know whether I still have commit access, but I can certainly send patches.

David Lawrence Ramsey <dolorous>
Group Member
Mon 23 Jul 2018 07:10:03 PM UTC, comment #5: 

David?  Have you started with this?  I ask because I'm looking at this too.  I would first want to pull ^J and M-J out of each other: to extract a function that is called once by ^J and called in a loop until reaching filebot by M-J.

Can we do this in a branch that I push to Savannah?  Do you still have commit access?  (Although, posting your patches for me to apply would work too.)  The steps do not have to retain full functionality -- later we can squash commits together to skip over the erring.

Benno Schulenberg <bens>
Group administrator
Sat 21 Jul 2018 07:27:14 AM UTC, comment #4: 

Oh, wow.  I didn't realize that Pico had evolved a bit in the meantime.  I have Pico 5.09 installed, and it too asks what to do when I hit ^J while some text is marked.  (Strangely, when several paragraphs are marked, it justifies this region into a single paragraph.)

Anyway... I don't think we should be looking at Pico right now.  Nor at FullJustify.  All we need at first is that a single ^J becomes undoable in the normal way: through the undo stack.  When that is possible, a series of ^Js will be undoable, and thus a full-justify too -- not in the way that one would like, but that is of later concern.  Important is that one can make and undo a justification without losing the undo stack.  What nano ought to do when the mark is on, etcetera, we can ignore for now.  One step at a time.

Benno Schulenberg <bens>
Group administrator
Fri 20 Jul 2018 01:57:48 AM UTC, comment #3: 

Unfortunately, my schedule has been filling up lately too.  I've looked into this, but I can't make any promises as to when I'll be able to do it.  I can at least tell you what should be happening.

To do this, nano should be putting the paragraph(s) to be justified into their own buffer, altering the text within that buffer instead of within the main file buffer of fileage/current/filebot, and then grafting it back in.  After that's the case, one would just need to use a temporary cutbuffer instead of a separate justify buffer, and then it should be undoable the same way the filtering operations are.

A normal justify and full justify could be treated almost identically, as the only real difference is that the former only justifies one paragraph, and the latter justifies multiple ones.  One major problem is how to deal with the mark if the alterations are made to the justify buffer, but it may not be as bad as it seems.

If you look at Pico as included in Alpine 2.20, its behavior with regard to justify has changed somewhat from previous versions, in ways that make the job of imitating it somewhat easier.  Specifically, if the mark is on, justify no longer shifts the mark relative to the text.  Instead, it prompts: "Justify Region, Paragraph; or fix Quotelevel?"

Selecting "Region" justifies only the marked text, selecting "Paragraph" justifies the next paragraph it finds (what older Pico and current nano both do), but notably turns the mark off.  Doing a full justify via ^W^U behaves the same (with one buggy behavior on Pico's part; if the mark is on, selecting "Region" will do nothing and stay at the prompt).  Selecting "Quotelevel" prompts for a number, and then adds that number of ">" characters to the left of each line of the justified paragraph.

Given that displaying such a prompt while justifying doesn't fit nano at all, and nano's quotelevel handling is much more advanced than Pico's as-is, the easiest way to imitate current Pico when the mark is on is for nano to justify only within the marked text: the current paragraph within the mark for a normal justify, and all paragraphs within the mark for a full justify.  This also means that mark adjustment will no longer be a problem when altering text in its own buffer while justifying.

This will, of course, be a notable change in behavior, but if properly documented, it should be easy to deal with.

David Lawrence Ramsey <dolorous>
Group Member
Wed 18 Jul 2018 06:11:02 PM UTC, comment #2: 

If you are willing to work on this, that would be great.  I have little time and energy to do much of anything these days.  But I will test any patch that you make.

Benno Schulenberg <bens>
Group administrator
Wed 18 Jul 2018 05:51:45 PM UTC, comment #1: 

Given that filtering the buffer (or marked region) through an external command can be undone/redone now, the code for that could probably be adapted to undo/redo justifying as well.

After all, both filtering and justifying effectively replace one multi-line chunk of text with another multi-line chunk of text (and, unlike commenting and indenting multiple lines, the latter is not required to have the same number of lines as the former).

David Lawrence Ramsey <dolorous>
Group Member
Thu 14 Jan 2016 04:44:29 PM UTC, original submission:  

Currently, when justifying a paragraph (^J), this can be undone with a special undo mechanism, only available right after the ^J.  Also, to prevent wrong things from being undone/redone, the general undo stack is discarded.

It would be much better if the general undo system also covered the justifying routines.

Benno Schulenberg <bens>
Group administrator

 

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

Attached Files
file #45486:  undoable-justification.zip added by bens (20KiB - application/zip)
file #45483:  justification-reworked.zip added by bens (26KiB - application/zip)
file #45125:  nano-justify-3e.zip added by dolorous (27KiB - application/zip)
file #45121:  nano-justify-3d.zip added by dolorous (27KiB - application/zip)
file #45116:  nano-justify-3c.zip added by dolorous (37KiB - application/zip)
file #45113:  nano-justify-3b.zip added by dolorous (37KiB - application/zip)
file #45099:  nano-justify-3a.zip added by dolorous (36KiB - application/zip)
file #45093:  nano-justify-3.zip added by dolorous (36KiB - application/zip)
file #45085:  nano-justify-2z.zip added by dolorous (36KiB - application/zip)
file #45084:  nano-justify-2y.zip added by dolorous (36KiB - application/zip)
file #45067:  nano-justify-2x.zip added by dolorous (36KiB - application/zip)
file #44981:  nano-justify-2x.zip added by dolorous (36KiB - application/zip)
file #44979:  nano-justify-2w.zip added by dolorous (36KiB - application/zip)
file #44978:  nano-justify-2v.zip added by dolorous (36KiB - application/zip)
file #44977:  nano-justify-2u.zip added by dolorous (34KiB - application/zip)
file #44976:  nano-justify-2t.zip added by dolorous (33KiB - application/zip)
file #44975:  nano-justify-2s.zip added by dolorous (33KiB - application/zip)
file #44974:  nano-justify-2r.zip added by dolorous (33KiB - application/zip)
file #44973:  nano-justify-2q.zip added by dolorous (33KiB - application/zip)
file #44971:  nano-justify-2p.zip added by dolorous (27KiB - application/zip)
file #44954:  nano-justify-2o.zip added by dolorous (24KiB - application/zip)
file #44948:  nano-justify-2n.zip added by dolorous (22KiB - application/zip)
file #44918:  nano-justify-2m.zip added by dolorous (21KiB - application/zip)
file #44917:  nano-justify-2l.zip added by dolorous (19KiB - application/zip)
file #44916:  nano-justify-2k.zip added by dolorous (19KiB - application/zip)
file #44914:  nano-justify-2j.zip added by dolorous (19KiB - application/zip)
file #44913:  nano-justify-2i.zip added by dolorous (17KiB - application/zip)
file #44912:  nano-justify-2h.zip added by dolorous (17KiB - application/zip)
file #44887:  nano-justify-2g.zip added by dolorous (17KiB - application/zip)
file #44883:  nano-justify-2f.zip added by dolorous (15KiB - application/zip)
file #44879:  nano-justify-2e.zip added by dolorous (13KiB - application/zip)
file #44878:  nano-justify-2d.zip added by dolorous (12KiB - application/zip)
file #44877:  nano-justify-2c.zip added by dolorous (13KiB - application/zip)
file #44873:  nano-justify-2b.zip added by dolorous (12KiB - application/zip)
file #44872:  nano-justify-2a.zip added by dolorous (9KiB - application/zip)
file #44865:  nano-justify-2.zip added by dolorous (10KiB - application/zip)
file #44864:  nano-justify-2.zip added by dolorous (9KiB - application/zip)
file #44839:  nano-justify.zip added by dolorous (29KiB - application/zip)
file #44825:  nano-justify.zip added by dolorous (16KiB - application/zip)
file #44648:  nano-justify.zip added by dolorous (8KiB - 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 pepa65 (Voted in favor of this item)
  • -email is unavailable- added by bens (Submitted the item)
  •  

    There are 3 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 25 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-25 bens Open/ClosedOpen Closed
    2018-11-20 bens StatusIn Progress Fixed
    2018-11-19 bens Attached File- Added undoable-justification.zip, #45486
    2018-11-18 bens Attached File- Added justification-reworked.zip, #45483
    2018-11-15 bens Severity3 - Normal 4 - Important
    2018-10-18 dolorous Attached File- Added 0002-justify-make-justify_paragraph-work-on-its-own-buffe.patch, #45241
    2018-10-02 dolorous Attached File- Added nano-justify-3e.zip, #45125
    2018-10-01 bens Attached File- Added 0003-moving-make-the-paragraph-movement-functions-work-on.patch, #45123
    2018-09-30 dolorous Attached File- Added nano-justify-3d.zip, #45121
    2018-09-29 dolorous Attached File- Added nano-justify-3c.zip, #45116
    2018-09-28 dolorous Attached File- Added nano-justify-3b.zip, #45113
    2018-09-25 dolorous Attached File- Added nano-justify-3a.zip, #45099
    2018-09-25 dolorous Attached File- Added nano-justify-3.zip, #45093
    2018-09-24 bens Attached File- Added report-the-adds-and-updates.patch, #45087
        Attached File- Added allow-a-paste-item-to-be-updated.patch, #45088
        StatusNone In Progress
        Assigned toNone dolorous
    2018-09-24 dolorous Attached File- Added nano-justify-2z.zip, #45085
    2018-09-24 dolorous Attached File- Added nano-justify-2y.zip, #45084
    2018-09-20 dolorous Attached File- Added nano-justify-2x.zip, #45067
    2018-09-13 dolorous Attached File- Added justify-small-test.txt, #45000
    2018-09-11 dolorous Attached File- Added nano-justify-2x.zip, #44981
    2018-09-11 dolorous Attached File- Added nano-justify-2w.zip, #44979
    2018-09-11 dolorous Attached File- Added nano-justify-2v.zip, #44978
    2018-09-11 dolorous Attached File- Added nano-justify-2u.zip, #44977

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code