unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Lars Ingebrigtsen <larsi@gnus.org>
To: Boruch Baum <boruch_baum@gmx.com>
Cc: 18183@debbugs.gnu.org
Subject: bug#18183: 24.3; table-fixed-width-mode fails with kill/yank
Date: Sun, 06 Dec 2020 15:30:29 +0100	[thread overview]
Message-ID: <877dpvc8hm.fsf@gnus.org> (raw)
In-Reply-To: <20201206090648.n23pfcopzkalkwqb@E15-2016.optimum.net> (Boruch Baum's message of "Sun, 6 Dec 2020 04:06:48 -0500")

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	other threads:[~2020-12-06 14:30 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-03 18:15 bug#18183: 24.3; table-fixed-width-mode fails with kill/yank Boruch Baum
2020-12-04 11:29 ` Lars Ingebrigtsen
2020-12-06  9:06   ` Boruch Baum
2020-12-06 14:30     ` Lars Ingebrigtsen [this message]
2020-12-06 18:20       ` Boruch Baum
2020-12-07 13:53         ` Lars Ingebrigtsen
2020-12-07 14:06           ` Lars Ingebrigtsen
2020-12-07 17:36             ` Boruch Baum
2020-12-07 18:21             ` Boruch Baum
2020-12-08 13:39               ` Lars Ingebrigtsen
2020-12-07 19:18             ` Boruch Baum
2020-12-08  7:18             ` Boruch Baum
2020-12-08 13:40               ` Lars Ingebrigtsen
2020-12-08 13:56                 ` Boruch Baum
2020-12-08 13:59                   ` Lars Ingebrigtsen
2020-12-08 14:30                     ` Michael Albinus
2020-12-08 14:49                       ` Lars Ingebrigtsen
2020-12-10 10:37                         ` Bastien
2020-12-14  9:36                           ` Boruch Baum
2020-12-14 18:21                             ` Bastien
2020-12-14 19:32                               ` Boruch Baum
2020-12-08  7:46             ` Boruch Baum
2020-12-07 16:02           ` Boruch Baum
     [not found]           ` <20201209115145.oamb5hjjv65bw23s@E15-2016.optimum.net>
2020-12-09 11:53             ` Boruch Baum
2020-12-09 19:35               ` Lars Ingebrigtsen
2020-12-10  7:04                 ` Boruch Baum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877dpvc8hm.fsf@gnus.org \
    --to=larsi@gnus.org \
    --cc=18183@debbugs.gnu.org \
    --cc=boruch_baum@gmx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).