From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Psionic K Newsgroups: gmane.emacs.devel Subject: Re: Introducing Master of Ceremonies, a package for presentations Date: Sun, 8 Dec 2024 16:14:04 +0900 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000e127e20628bcfeac" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34389"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Emacs developers To: Psionic K , bugs@gnu.support Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 08 08:15:07 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tKBVR-0008kn-Ow for ged-emacs-devel@m.gmane-mx.org; Sun, 08 Dec 2024 08:15:05 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tKBUl-0000ex-8Y; Sun, 08 Dec 2024 02:14:23 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tKBUh-0000eB-Ap for emacs-devel@gnu.org; Sun, 08 Dec 2024 02:14:19 -0500 Original-Received: from mail-yb1-xb2d.google.com ([2607:f8b0:4864:20::b2d]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tKBUf-00075d-G4 for emacs-devel@gnu.org; Sun, 08 Dec 2024 02:14:19 -0500 Original-Received: by mail-yb1-xb2d.google.com with SMTP id 3f1490d57ef6-e3a0acba5feso1475470276.2 for ; Sat, 07 Dec 2024 23:14:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=positron.solutions; s=google; t=1733642055; x=1734246855; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RXxQNd47G/olxV6rnvBeY8qbccmvD6AqmNom9yb0MSE=; b=ep8JhOZQqCqgAObLnW9WI+eRADiuq/VDchhCh2kfYt7pICIxaWlv7+QGXXePLd9JL/ hRmD7kR61AnpELuts7EK6FPtoFY6nTGQIdT6r1DI/QT8RPwkFnvfcZPYb7nTwSx/cens iu8/Be1SSqLxQR9txqqs8ypm3OF3Du/rUbIUEN0WnuzWSaG7bYGMCCOHR3oSHCTuPokk j/wzN32M0kiT6LO31YIyLsMBjBEvz5+YqNgBmFM0wby0cok7XdF+yYDQzq48v/kv1aJI 94J0C4A8XpZinzkaxZkfvqEsz7PaWmUFcMBkHpZKM1RfJNg6t4Hbfcvyqi9+4SCZe+jf Ye8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733642055; x=1734246855; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RXxQNd47G/olxV6rnvBeY8qbccmvD6AqmNom9yb0MSE=; b=IMB5vOWMN0gVE+NhrrWEDrVW7P00cX5/tvq+7tysATN4SfjiF+ilZQv2PvCP9IuLfn +5gvm7/zMiayFAGr6JSzn0WvdZTGpPkmIr6U6WIFHxhOdAs4NhlmijrzSHEBQfYUj/fJ BDc83aeCjaat8ZjKeJXlHxdvBBJePHkPdPdW9cwFgKqzZWPN0WJQrGSvSWWc6xGZ8JUM edwBChsk2yqxSPynW6/TU27GJwosMMhWm50BBboiCxmukz+1EOH+1YP7TkvyewWE2roz vAdHBK6snzXFNFL53T1lKIucMDISYQDiRj8diTsuDgxNLcRPZmgwnqn7fh1EOVF66jFy 0otw== X-Gm-Message-State: AOJu0YzhUGBDE6gxLt4oyi28TFWz+pK5zrZhPe91aJG+PB2Aqw67pazI Qj2UQzcYG39DufIL/AnW7l0rB5Vmdl7afWlKqeLVquAIvV6qmspZvGULSh2lcK5ttrXq/wjkEUf FEU3NOMOWJ3sjVdefz3nFJ63086p+SXqQI0ZG1Q== X-Gm-Gg: ASbGncsKDPkgMpXKDDrf679jJ8gHyCeZgQtUmfOHZI/+g47IpEHdMS6IpYaW5YAdIkA snUzNfSMlbX8pixv4nW0jkLn8MVQccRwUAQ== X-Google-Smtp-Source: AGHT+IG3WOE98UZo7w2dMYRMG3+AMZcgR4T1vLR0qlsUGZNhObUQ9axXDvzwV4guEzvXRnsr8OR+v+t7Ok6U65luGvI= X-Received: by 2002:a05:6902:e04:b0:e38:99df:540b with SMTP id 3f1490d57ef6-e3a0b6ba185mr6778939276.47.1733642055386; Sat, 07 Dec 2024 23:14:15 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::b2d; envelope-from=exec@positron.solutions; helo=mail-yb1-xb2d.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:326180 Archived-At: --000000000000e127e20628bcfeac Content-Type: text/plain; charset="UTF-8" I have pushed master with some packaging related fixups to make progress on adding to MELPA / Non-GNU ELPA. Among changes, I have adopted a new strategy that leans on Emacs text editing. The result is much more satisfactory than the overlay stitching and translation I had started work on in another stash which will now be deleted. As a benefit, we finally have some basic whitespace cleanup and indentation preservation when selections do not begin at a line beginning, such as can be required if the preceding text is not whitespace. What remains is an implementation of rectangle trimming and following up on my continuation strategy, I will describe below. > remove any double horizontal white space from sentences or paragraphs User responsibility. I can't make everyone or a reliable majority happy with either decision and input text expresses these decisions or should. > It is presenting well, but only short words. It should at least > present well sentences and paragraphs. The new `:continuation` key in `moc-focus` replay arg plist reveals my strategy for this. I read the state of `visual-line-mode` and `adaptive-wrap-prefix-mode`. I will default to truncation when these are not active. When they are active, I can calculate the right size as described earlier and allow Emacs logic to wrap the text. If in the future text can be justified by an overlay or buffer-wide via a mode, it will be easy to support, but I will not manually re-flow text because that is just asking to re-implement and maintain the entire ball of yarn in Elisp, an endeavour of very limited value to me and one that has workarounds for the user: Turn off read-only mode and make some edits. When filling code with long lines and comments etc, the user's fill column will usually be what they want. I don't want to reflow Elisp code without a lot more intelligence. That is LLM work, not fiddly text editing rule and heuristic based work. Truncation is very robust at limiting the max width. For visual lines, along with the continuation strategy described above, I am implementing a minimum character width, which is a heuristic to avoid re-shaping text that is extremely short, below 30 characters or so. Don't want one word per line. I can do manual justification, but honestly why not just do this with specified space in Emacs and apply a text property if desired? My implementation will be useless by comparison in terms of coverage. Images can center. Why not text? --000000000000e127e20628bcfeac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I = have pushed master with some packaging related fixups to make progress on a= dding to MELPA / Non-GNU ELPA.=C2=A0 Among changes, I have adopted a new st= rategy that leans on Emacs text editing.=C2=A0 The result is much more sati= sfactory than the overlay stitching and translation I had started work on i= n another stash which will now be deleted.

As a benefit, we finally have some basic whitespace clean= up and indentation preservation when selections do not begin at a line begi= nning, such as can be required if the preceding text is not whitespace.

What remains is an implementation of rectangle trim= ming and following up on my continuation strategy, I will describe below.

> remove any double horizontal white space from sentenc= es or paragraphs

User responsibility.=C2=A0 I can't m= ake everyone or a reliable majority happy with either decision and input te= xt expresses these decisions or should.

> It is presen= ting well, but only short words. It should at least
> present well se= ntences and paragraphs.

<= span class=3D"gmail-im">The new `:continuation` key in `moc-focus` replay a= rg plist reveals my strategy for this.=C2=A0 I read the state of `visual-li= ne-mode` and `adaptive-wrap-prefix-mode`.=C2=A0 I will default to truncatio= n when these are not active.=C2=A0 When they are active, I can calculate th= e right size as described earlier and allow Emacs logic to wrap the text.= =C2=A0 If in the future text can be justified by an overlay or buffer-wide = via a mode, it will be easy to support, but I will not manually re-flow tex= t because that is just asking to re-implement and maintain the entire ball = of yarn in Elisp, an endeavour of very limited value to me and one that has= workarounds for the user:=C2=A0 Turn off read-only mode and make some edit= s.

When filling code with= long lines and comments etc, the user's fill column will usually be wh= at they want.=C2=A0 I don't want to reflow Elisp code without a lot mor= e intelligence.=C2=A0 That is LLM work, not fiddly text editing rule and he= uristic based work.=C2=A0 Truncation is very robust at limiting the max wid= th.

For visual lines, alo= ng with the continuation strategy described above, I am implementing a mini= mum character width, which is a heuristic to avoid re-shaping text that is = extremely short, below 30 characters or so.=C2=A0 Don't want one word p= er line.

I can do manual = justification, but honestly why not just do this with specified space in Em= acs and apply a text property if desired?=C2=A0 My implementation will be u= seless by comparison in terms of coverage.=C2=A0 Images can center.=C2=A0 W= hy not text?
--000000000000e127e20628bcfeac--