From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: face vs. mouse-face text property Date: Mon, 23 Jan 2012 09:27:36 -0500 Message-ID: References: <87pqegeluf.fsf@web.de> <87y5t2f7q0.fsf@web.de> <83vco52wph.fsf@gnu.org> <87bopv8jla.fsf@web.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1327328889 1810 80.91.229.12 (23 Jan 2012 14:28:09 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 23 Jan 2012 14:28:09 +0000 (UTC) Cc: michael_heerdegen@web.de, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 23 15:28:02 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RpKsI-0008Pp-DS for ged-emacs-devel@m.gmane.org; Mon, 23 Jan 2012 15:27:58 +0100 Original-Received: from localhost ([::1]:34351 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpKsH-0006Nc-Nm for ged-emacs-devel@m.gmane.org; Mon, 23 Jan 2012 09:27:57 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:41080) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpKsB-0006NP-Vw for emacs-devel@gnu.org; Mon, 23 Jan 2012 09:27:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpKs2-0000SU-JQ for emacs-devel@gnu.org; Mon, 23 Jan 2012 09:27:51 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:64001) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpKrx-0000Rn-L7; Mon, 23 Jan 2012 09:27:37 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAN9tHU9MCos2/2dsb2JhbABChQmpG4EGgXIBAQQBIzMjBQsJAhoCGA4CAhQYDSSID6cJkRKBL4lhgRYEiDuac4RX X-IronPort-AV: E=Sophos;i="4.71,556,1320642000"; d="scan'208";a="158204192" Original-Received: from 76-10-139-54.dsl.teksavvy.com (HELO pastel.home) ([76.10.139.54]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 23 Jan 2012 09:27:36 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 2CB9758D29; Mon, 23 Jan 2012 09:27:36 -0500 (EST) In-Reply-To: (Eli Zaretskii's message of "Mon, 23 Jan 2012 01:48:46 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:147846 Archived-At: > Therefore, I think if we want to be able to display selectable > newlines, we need to have a special way to display such newlines, > e.g. "" or some such. I'd suggest \n rather than , since it's already used at many other places in Emacs (tho it's not often visible to the "end user"). There are other similar issues in the *Completions* lists if you have completions which start/end with spaces or tabs, are very long, or worse only contain spaces or tabs: while the mouse-over will be reasonably clear, the list is far from clear if you don't move your mouse over it to see the exact boundaries. Currently, completions are used for entities which typically don't suffer from such issues. But if we want to use it for things like yank-browse (see sample code below), we need to make it handle such cases a bit better. Stefan (defun yank-browse (string) "Browse the `kill-ring' to choose which entry to yank." (interactive (minibuffer-with-setup-hook #'minibuffer-completion-help (let* ((kills (delete-dups (append kill-ring-yank-pointer kill-ring ni= l))) (entries (mapcar (lambda (string) (let ((pos 0)) ;; FIXME: Maybe we should start by removing ;; all properties. (setq string (copy-sequence string)) (while (string-match "\n" string pos) ;; FIXME: Maybe completion--insert-strings should ;; do that for us. (put-text-property (match-beginning 0) (match-end 0) 'display (eval-when-compile (propertize "\\n" 'face 'escape-glyp= h)) string) (setq pos (match-end 0))) ;; FIXME: We may use the window-width of the ;; wrong window. (when (>=3D (* 3 (string-width string)) (* 2 (window-width))) (let ((half (- (/ (window-width) 3) 1))) ;; FIXME: We're using char-counts rather than ;; width-count. (put-text-property half (- (length string) half) 'display (eval-when-compile (propertize "=E2=80=A6=E2=80=A6" '= face 'escape-glyph)) string))) string)) kills)) (table (lambda (string pred action) (cond ((eq action 'metadata) '(metadata (category . kill-ring))) (t (complete-with-action action entries string pred))))= )) ;; FIXME: We should return the entry from the kill-ring rather than ;; the entry from the completion-table. ;; FIXME: substring completion doesn't work well because it only mat= ches ;; subtrings before the first \n. ;; FIXME: completion--insert-strings assumes that boundaries of ;; candidates are obvious enough, but with kill-ring entries this is= not ;; true, so we'd probably want to display them with =C2=AB...=C2=BB = around them. (list (completing-read "Yank: " table nil t))))) (setq this-command 'yank) (insert-for-yank string))