GNU bug report logs - #18183
24.3; table-fixed-width-mode fails with kill/yank

Previous Next

Full log

Message #16 received at 18183 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: 18183 <at> debbugs.gnu.org
Subject: Re: bug#18183: 24.3; table-fixed-width-mode fails with kill/yank
Date: Sun, 06 Dec 2020 15:30:29 +0100

Boruch Baum <boruch_baum <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.