[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#18183: 24.3; table-fixed-width-mode fails with kill/yank
From: |
Lars Ingebrigtsen |
Subject: |
bug#18183: 24.3; table-fixed-width-mode fails with kill/yank |
Date: |
Sun, 06 Dec 2020 15:30:29 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Boruch Baum <boruch_baum@gmx.com> writes:
>> > typing directly into a cells in tables does not change the size of the
>> > cell when table-fixed-width-mode is set; however, yanking and killing
>> > within a cell does change the size of the cell.
>>
>> (This bug report unfortunately got no response at the time.)
>>
>> Do you have a recipe, starting from "emacs -Q", to reproduce this bug?
>
> Yes. A form of this bug is reproducible in emacs-snapshot,
> inconsistencies of mode's definition, so I'm providing a recipe for the
> simplest case, tested in an October version of emacs-snapshot.
>
> After opening a fresh emacs:
>
> 1) find an org-mode file
> 2) create an org-mode heading line just to show you're in org mode, eg
> * foo
> 3) M-x table-fixed-width-mode
> 4) Verify by evaluating table-fixed-width-mode and getting a 't' result
> 5) Create a table, using the defaults of M-x table-insert
> 6) C-c ' to edit the current table cell
> 7) Insert a string greater than the cell width. The expected behavior is
> "A word that is too long to fit in a cell is chopped into multiple
> lines". Note that is not the case within the cell editor pop-up
> buffer. Rather the cell width is expanded.
> 8) Save your cell-edit changes using C-c '. Note the persistence of the
> unexpected behavior.
>
> My vague vague memory of the distant past when I submitted the bug
> report was that the unexpected behavior was different, as described in
> my initial report, but some form of that original bug remains, just now
> it's more consistent, and behaves just as badly whether inserting or
> yanking text into a cell.
I see the same behaviour on the trunk.
> At this point, since the behavior is consistent, a lazy way to 'fix' the
> bug might be to just change the docstring...
Well, that would make table-fixed-width-mode useless? (Which it is,
indeed, already.)
I tried debugging this, and while there is a bunch of code to handle the
fixed-width setting, I don't understand the code.
table--cell-insert-char always inserts non-space chars, no matter what
the setting is, and then table--measure-max-width measures the new
width, which makes table-with-cache-buffer widen the cell.
So I'm wondering -- has this ever worked?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
- bug#18183: 24.3; table-fixed-width-mode fails with kill/yank, Lars Ingebrigtsen, 2020/12/04
- bug#18183: 24.3; table-fixed-width-mode fails with kill/yank, Boruch Baum, 2020/12/06
- bug#18183: 24.3; table-fixed-width-mode fails with kill/yank,
Lars Ingebrigtsen <=
- bug#18183: 24.3; table-fixed-width-mode fails with kill/yank, Boruch Baum, 2020/12/06
- bug#18183: 24.3; table-fixed-width-mode fails with kill/yank, Lars Ingebrigtsen, 2020/12/07
- bug#18183: 24.3; table-fixed-width-mode fails with kill/yank, Lars Ingebrigtsen, 2020/12/07
- bug#18183: 24.3; table-fixed-width-mode fails with kill/yank, Boruch Baum, 2020/12/07
- bug#18183: 24.3; table-fixed-width-mode fails with kill/yank, Boruch Baum, 2020/12/07
- bug#18183: 24.3; table-fixed-width-mode fails with kill/yank, Lars Ingebrigtsen, 2020/12/08
- bug#18183: 24.3; table-fixed-width-mode fails with kill/yank, Boruch Baum, 2020/12/07
- bug#18183: 24.3; table-fixed-width-mode fails with kill/yank, Boruch Baum, 2020/12/08
- bug#18183: 24.3; table-fixed-width-mode fails with kill/yank, Lars Ingebrigtsen, 2020/12/08
- bug#18183: 24.3; table-fixed-width-mode fails with kill/yank, Boruch Baum, 2020/12/08