bug-gnu-emacs
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]