GNU bug report logs - #37325
About 'latex-insert/close-block' in 'latex-mode'

Previous Next

Package: emacs;

Reported by: Sebastian Urban <mrsebastianurban <at> gmail.com>

Date: Fri, 6 Sep 2019 17:32:01 UTC

Severity: minor

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


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

From: Sebastian Urban <mrsebastianurban <at> gmail.com>
To: eliz <at> gnu.org
Cc: 37325 <at> debbugs.gnu.org
Subject: bug#37325: About 'latex-insert/close-block' in 'latex-mode'
Date: Thu, 23 Apr 2020 14:29:07 +0200
So, I revisited this bug and I should update it.

> 1.  Why so many key bindings?  Can we have 'C-c [' for "insert" and
> 'C-c ]' for "close" - and just that?  When I do 'C-c [' it's
> "undefined", so maybe...

After looking into "tex-mode.el" I found explanation in
"tex-mode-map":

 ;; Redundant keybindings, for consistency with SGML mode.
 (define-key map "\C-c\C-t" 'latex-insert-block)
 (define-key map "\C-c]" 'latex-close-block)
 (define-key map "\C-c/" 'latex-close-block)

This group is separated from other keybindings with empty lines, so
I'm guessing by default "C-c C-o" inserts block and "C-c C-e" closes
block, the rest (C-c C-t, C-c ], C-c /) are additional shortcuts.
Therefore I think this part of the bug can be "closed".

> 2.  When I use 'where-is' on both aliases I get (echo area, 2
> lines):
>
> tex-latex-block is not on any key;
>  its alias latex-insert-block is on C-c C-t, C-c C-o
>
> If I'm not mistaken, it says that 'latex-insert-block' is an alias
> for 'tex-latex-block' when it's completely otherwise.  So 2nd line
> should rather say:
>
>  it's na alias for latex-insert-block, which is on C-c C-t, C-c C-o
AND quoting Eli:
> It sounds like the code which adds aliases treats an alias as a
> symmetric relation.  Not sure if this is correct.

You might be right, because e.g. in "hi-lock.el" there is:

 (defalias 'highlight-lines-matching-regexp 'hi-lock-line-face-buffer)

After using "where-is" on "hi-lock-line-face-buffer" I get:

 hi-lock-line-face-buffer is not on any key;
  its alias highlight-lines-matching-regexp is on M-s h l

It seems to be OK, because "highlight-lines-matching-regexp" is an
alias for "hi-lock-line-face-buffer".

But I think this way of handling aliases is wrong.  According to the
dictionary alias is a "false name", which means no symmetric relation.
Name B can be false name for Real Name A, but not the other way (going
further Name B can have additional false name in form of Name C etc.).
I hope I didn't mess this up.  So while it does the job in example
from "hi-lock.el", it fails in example from "tex-mode.el", which means
the function should be corrected to have 2 strings, current one (its
alias) and perhaps suggested by me - "it's an alias for".

> 2.1.  Why the one char indent in 2nd line?
AND quoting Eli:
> As for the extra blank, I think it's a matter of personal preference
> whether it improves the display or makes it worse.

Well, since it indicates (form similar to unordered list) that second
line is "continuation" of information from first line, rather than new
information, it could stay as it is.  So this part can be also
"closed".

> 3.  In INFO 25.11.2 "LaTeX Editing Commands" for 'C-c C-o' alias
> 'tex-latex-block' is used and for 'C-c C-e' alias
> 'tex-close-latex-block' is used - why not real functions names:
> 'latex-insert-block' and 'latex-close-block'?  They would even sound
> better (look at the name of the section).

And this is a bug.  In "tex-mode.el", under "tex-mode-map", there is:

 (define-key map "\C-c\C-o" 'latex-insert-block)
AND
 (define-key map "\C-c\C-e" 'latex-close-block)

In "text.texi", lines 1666, 1669, 1676 and 1691 should be updated.

> 4.  And then, after all, are those aliases needed at all?

As I searched through "tex-mode.el", I was able to find them
("tex-close-latex-block" and "tex-latex-block") only where they are
defined as an alias.  So if they are not used somewhere outside, maybe
they could be removed?


S. U.




This bug report was last modified 3 years and 192 days ago.

Previous Next


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